On 02.12.2010 01:01, Jaap Frank wrote:
 > That's odd, because for me the 3.6 side is correct and the 3.7 side is
 > far too bright.
 > I've a rather new HD LCD TFT monitor (about 6 months) and adjusted it
 > conform the windows 7 system with brightness and contrast followed by
 > color shade correction.
 > Further the monitor of my laptop (Acer Aspire, 1 year old, crystal clear
 > display) shows exactly the same picture. Both are driven by the NVidia
 > card inside the laptop, so they should be the same and for /me/ they
 > are. The pictures are displayed by Windows Live Mail.

Trust me, Warp is correct and if you see it different there is something 
screwed up with your display system. One cannot *perfectly* calibrate a 
display without usage of some external hardware but for, let's say 
hobbyist usage, there are quite a lot tools (and web-pages) around that 
allow for visual adjustment but all of them boil down to something 
similar Warp has shown.


 > I'm wondering if the default 3.7 approach is correcting the values for a
 > 2.2 gamma display in the file, while the display system thinks it gets
 > lineair values and correct the values again. That would explain the 3.7
 > side for me. (The jpg and png files are the same for me, so that can't
 > be the problem)
 > By the way, the challenge from clipka is for me a perfect gradient from
 > 0,0 to 1,1 in the XY-plane. I suspect that this picture is made with
 > 3.7, so that is odd again.
 >
 > I'm reading the Gamma Stories for months now and all the same I'm 
confused.
 > Maybe clipka can answer what is correct:
 > Povray makes a calculation for a picture and the values of the first
 > three pixels are 64,64,64 / 128,128,128 / 192,192,192.
 > As I understand these are the values of PovRay's internal lineair color
 > space.
 > My questions are:
 > A. What values are send to the display system at the moment of rendering:
 > 1. Gamma corrected values for a 2.2. display, so not the lineair values.
 > 2. Lineair values and PovRay tells the display system to convert them to
 > 2.2 display values:
 > B. What values are written in the png file and what is put in the gAMA
 > chunk.
 > 1. Same as A.1. and the gAMA chunk tells the values are gamma corrected
 > for 2.2.
 > 2. Same as A.2. and the gAMA chunk tells that the correct values should
 > be 2.2 corrected values (sounds not correct, but you never can tell).
 > To complete the story:
 > C.1. PovRay expects the file for a image-texture on a object to be gamma
 > corrected (default 2.2) and counter corrects the values for it's lineair
 > color space.
 > 2.Same, but the correction depends on the gAMA blok. With no gAMA a 2.2
 > correction is used.
 >
 > I think that the answers are A.1 and B.1, but sometimes I begin to doubt
 > that, as I read these gamma stories.
 > As far as I've understood C.1 is 3.6 and C.2 is 3.7 policy.
 >

A.1. but the actual value can be adjusted by the display_gamma setting 
with the recommended default of 2.2 (unless you know what you are doing ;)
B.1. but the actual value can be adjusted by the file_gamma setting with 
the recommended default of 2.2 (unless you know what you are doing ;-P) 
and the exception of high dynamic range formats being always encoded 
linear (as they should be by definition).

C.2. is true for POV-Ray 3.7 AND 3.6 and PNG input format except when no 
gamma chunk was present when POV-Ray 3.6 did apply no correction at all 
(see below).

C.1. is true for POV-Ray 3.7 and any other format than PNG
BUT POV-Ray 3.6 did use the gamma encoded values internally directly 
without converting them to linear color space and this was plain wrong!

-Ive (and sorry for sending the mail - this happens to me all the time, 
I really should learn how to use Thunderbird)

Post a reply to this message